Well.. tests are fine now but I realised that i.e. chrome was not able to "decode" the data. I'm fighting right now to support php5.3+ with different encoding methods.

By now this code does not work properly. I'm working on a solution..

Couple of commits and some changes added but finally I think we got a working example across all versions 🎉 Looking forward for your reviews!

What's missing is a detection if the response is actually compressible. A simple check would to test the Content-Type header of the response for text/*, */*+json, */*+text, */*+xml which should cover 99% of the cases. A more comprehensive solution would be to use something like https://cdn.rawgit.com/jshttp/mime-db/master/db.json to lookup the compressible property of the content type.

@jsor very good point 👍 After some research I found out there's 2 approaches around the web servers..

• auto detection and compression (i.e. node with compressible + mime-db packages)
• manual definition of compressible mime's (i.e. apache, nginx, lighthttpd, MS iis)

Which way do we want to go?
My personal opinion would be a manual definition as the users are probably more used to it from the big players like nginx.

To be open for approaches I would suggest to inject the logic through an interface..

Interface + Class

interface CompressibleInterface {
    public function isCompressible(string $mime) : bool;
}
class CompressionGzipMiddleware {
   public function __construct(CompressibleInterface $detector, $level = -1) {}
}

Usage example#1 with auto-detection

new CompressionGzipMiddleware(new class implements CompressibleInterface {
    public function __construct() { // fetch mime-db from remote or local file }
    public function isCompressible($mime) {}
});

Usage example#2 with manual definition

new CompressionGzipMiddleware(new class(['application/text', 'application/json']) implements CompressibleInterface {
    public function __construct(array $mimes = []) {}
    public function isCompressible($mime) {}
});

@christoph-kluge Thank you for filing this PR, much appreciated! 👍 I really like seeing these new middleware handlers pop up!

Given the current discussion in #221 it looks like this middleware handler may be better off in a separate package instead of being part of react/http. I agree that this middleware handler may use a number of different strategies to decide which content should be compressed as per your above discussion. I feel that these strategies are beyond the scope of this package at the moment, so I would much rather have all the relevant strategies available somewhere and then prominently link to this instead.

What do you think about this?

I also think this middleware might be better suited for a dedicated package since the discussion has shown, that it will grow beyond a single simple middleware class. That way, it can define its own interfaces and dependencies, eg. for the platform requirement if you want to drop support for PHP 5.3.

@jsor @christoph-kluge @clue what do you think of putting this under the https://github.com/friends-of-reactphp umbrella?

@WyriHaximus @jsor @clue after the discussion in #221 and re-reading the rfc2616 (3.5 Content Codings) I would expect that we have a compression middleware here for handling the basic reading and writing of the headers and allow custom tokens through an CompressionTokenInterface..

So we could end up with http-support here and add custom tokens like gzip, deflate, br inside https://github.com/friends-of-reactphp?

what do you think?

Since we're currently focussing on ironing out the core middleware system, i propose the following steps:

1. Create a personal repository for a compression middleware and do a prototype there. Feel free to ping me there for review.
2. Once the protoype is ready, we're proposing it to the Friends of ReactPHP organisation. (FYI: the organisation is currently just a placeholder which we plan to bring to live in the foreseeing future.)
3. Promote the middleware in the react/http repo, eg. in the README.

What do you think?

@jsor sound very reasonable to me. Will ping you as soon as it's ready :)

@christoph-kluge please ping me as well, would love to take it for a test and provide feedback 👍